This doesn't create the ideal behavior and the implementation is hard to defend either. Looking into alternatives

Might be good to add some tests, in particular for checking that opt_clean -x and setundef -undriven -undef; opt_clean are equivalent.
Am I also right in saying that opt -full wouldn't benefit from this, since opt_expr -full (or more specifically, opt_expr -undriven) already replaces undriven bits with x-bits?

Also given that setundef and opt_expr both use -undriven and refer to it as "replace undriven nets with undef (x) constants" in the help, it would be good to be consistent here (unless I'm misinterpreting, and this isn't the same).

I think in a synthesis context it makes more sense to treat constant 'z as undriven and 'x as driven but don't care, but also (optionally?) allow used-but-never-driven values to be converted into don't cares (producing a warning when that happens). Without that distinction, I'd be worried about what could happen to bidirectional signals.

For bufnorm I also had to add code to opt_clean to handle a buffered 'z signal as undriven, which moves us slightly in that direction. It doesn't really make sense from an EE perspective, but some way to mark a subset of the outputs bits of a $buf as undriven was an absolute requirement to make bufnorm work in the presence of bidirectional connections, and that seemed like the least risky choice.

While that was a somewhat forced step, I feel like we should have a discourse thread on how to make 'z, 'x and undriven more consistent and meaningful before deciding to merge changes to specific passes. Especially if there is a chance we will replace bufnorm with signorm which would allow us to undo this forced step.